标签：Memory Management

共 35 篇相关文章

IT 累计浏览 3,561

Linux内存中的Cache真的能被回收么？

这篇讲的是Linux系统中一个经典但常被误解的问题：那些被buffer和cache占用的内存，到底能不能在需要时被释放。文章从`free`命令的输出切入，指出了三种不同层次的理解，并重点剖析了第二种——即很多人认为buffer/cache内存“随时可释放”的认知其实并不完全准确。作者清晰解释了page cache和buffer cache的核心区别：前者主要用于缓存文件读写，后者用于块设备I/O缓存。Linux内核确实会在内存压力大时回收这些缓存，但这个过程并非没有代价——回收前必须确保缓存数据与磁盘文件一致，往往会导致瞬间的IO飙升。文章的真正价值在于通过一个具体的tmpfs实验揭示了回收的边界。当把大量数据存入基于内存的tmpfs文件系统时，这部分内存会体现在`cached`指标里，`free`命令也提示有很多“可用”内存。然而，当尝试手动执行`echo 3 > /proc/sys/vm/drop_caches`进行回收时，这部分内存却无法被释放，因为它本质就是系统分配给tmpfs的物理内存，不属于可回收的缓存范畴。因此，结论很明确：并非所有在`free`命令中显示为“cached”的内存都能被回收。像tmpfs这类“内存就是存储”的场景，占用的空间是“实实在在”的已使用内存，这与加速文件访问的磁盘缓存有本质区别。理解这一点，对于准确评估系统内存压力至关重要。

IT 累计浏览 3,440

一个Laravel队列引发的报警

作者从一次诡异的服务器报警说起：集群中某台服务器内存飙高，但通过常规命令却查不到内存大户。通过对比不同服务器的进程列表，线索最终指向了 Laravel 队列。深入排查后发现，问题的根源并非进程自身，而是 Laravel 队列在默认的监听模式下，其子进程会频繁重启。每次重启都会创建并删除大量临时文件，导致 Linux 系统内核中的 dentry 缓存（目录项缓存）被急剧撑大，从而“吃掉”了大量内存。文章通过 strace 跟踪清晰地捕捉到了这一过程。针对这一问题，作者提供了两个层面的解决方案：一是应用层面，强烈推荐启用 Laravel 队列的守护进程模式，避免不必要的进程重启；二是系统层面，在无法避免频繁文件操作时，可以通过调整内核参数如 `vfs_cache_pressure` 来尝试缓解。整篇文章完整展现了从现象入手，借助工具抽丝剥茧，最终定位到内核缓存层面问题的精彩排查思路。

IT 累计浏览 3,661

GDB 进行程序调试笔记

这篇笔记详细记录了从零开始使用 GDB 调试 C 程序的全过程。作者以一段包含循环累加的简单 C 代码为例，清晰地展示了调试前的必要准备——必须使用 `gcc -g` 参数编译，将源码信息嵌入二进制文件，这是所有调试操作的基础。进入 GDB 后，文章没有罗列枯燥的命令列表，而是通过实操讲解了最核心的流程：用 `start` 启动程序，用 `list` 查看源码；在函数调用处，区分了 `next`（单步执行不进入函数）与 `step`（进入函数内部）的不同用途。当进入 `add_range` 函数后，通过 `backtrace` 查看函数调用栈帧，用 `info locals` 和 `print` 命令观察局部变量的状态，甚至演示了如何用 `set var` 在运行时修改变量值。最后，以一个命令表格收尾，汇总了 `bt`、`finish`、`frame` 等高频命令的用途。它本质上是一份面向初学者的 GDB 速查手册，重点突出了调试过程中“查看”与“干预”程序状态的两大核心能力，对于不熟悉命令行调试的开发者来说，是非常实用的入门参考。

IT 累计浏览 4,443

软件开发的硬约束

这篇讲的是作者从超市结账小票的两种打印方式出发，对软件开发中“软约束”与“硬约束”的深刻反思。作者观察到，收银小票倾向于为同一件商品打印多行记录（每行数量为1），而非合并成单行（数量为N），即使后者更省纸。起初他怀疑是设备性能所限，但通过一次收货管理系统的开发与实地部署，他发现了真正的原因：合并记录会影响仓库作业流程的效率与操作习惯——后续员工需要在纸质清单上手动划销，单件单行才最直观。这个发现让他意识到，长期从事纯软件开发时，功能、架构与责任划分往往具有灵活性（“软约束”），可以按需调整。但现实世界存在大量“硬约束”，比如设备操作习惯、生产线工艺流程、物理环境限制等。他进一步以工厂生产多语言说明书为例：生产线难以像软件模块一样灵活拆分组合，导致不得不为所有市场印刷包含所有语言的通用说明书，以避免为每种语言维护独立生产线的高昂成本。作者总结道，随着软件深入物理世界，决定其价值的往往不是复杂的技术架构，而是能否与现实约束融洽相处。开发者需要跳出纯粹的代码思维，直面问题的核心限制。文章最后以快递站利用条码替代键盘操作的巧妙案例收尾，说明了解决方案可以完全跳出技术框架，以极低成本满足场景的真实需求。

IT 累计浏览 12,741

关于linux内存free的一些事情

这篇讲的是Linux下最常用也最容易被误解的free命令。文章从一个最常见的命令入手，拆解了其输出中每一列的含义，特别是新手容易混淆的“buffers”和“cache”——前者是写缓存，后者是读缓存。作者指出，判断系统内存是否充足，关键看“-/+ buffers/cache”这一行，而非仅看“free”列。因为可供应用程序使用的内存总量实际上是“free + buffers + cached”的总和。文章还解释了一个经典困惑：为何系统已开始使用Swap，却可能并未“内存不足”？这是因为在内存紧张时，系统会尝试释放旧的缓存，但有时释放不及时，便过渡到了交换区。此外，文章也演示了如何使用`sysctl`手动释放缓存，并坦诚这通常是“治标不治本”的操作，缓存会在系统运行中再次积累。这对于运维人员日常排查“内存告警”误报、理解系统真实资源状况有直接的指导意义。

IT 累计浏览 2,340

小心 int 乘法溢出!

这篇讲的是 C/C++ 编程中一个隐蔽却危害巨大的陷阱：32 位 `int` 类型在进行乘法运算时可能发生的溢出问题。作者从一个实际场景切入——试图用 `malloc()` 分配 3000MB 内存时，代码 `mb * 1024 * 1024` 由于 `int` 只有 32 位，其计算结果早已溢出为负值 `-1073741824`。这个负值作为 `size_t`（64位系统中是64位无符号整数）参数传入 `malloc`，会被解释成一个天文数字（约 1844 亿亿），导致分配请求远超预期，引发程序崩溃或内存损坏。文章特别点明，这种错误非常具有迷惑性，因为无论操作系统是 32 位还是 64 位，`int` 通常是 32 位的。作者以亲身在 SSDB 项目中多次踩坑的经历作为佐证，强调了问题的普遍性与现实危害。核心告诫在于：当运算结果可能超出 `int` 范围，尤其是作为内存大小等参数时，必须显式地进行类型转换或选用合适的数据类型（如 `size_t`），以确保计算的正确性与安全性。对于处理大数据的系统开发者而言，这是个值得时刻警惕的细节。

IT 累计浏览 6,064

如何实现一个malloc

很多用C语言的程序员都熟悉 `malloc` 这个函数，但它既不是C关键字也不是系统调用，其背后的实现原理常被忽略。这篇讲的是如何从零开始实现一个简易的 `malloc`，帮助读者理解内存分配器的核心思想。文章从现代操作系统的内存管理基础讲起，清晰梳理了虚拟内存、页表、Linux进程内存布局等关键概念，特别聚焦于堆内存管理和 `brk`/`sbrk` 系统调用。作者先给出了一个只增不减的“玩具实现”，直观展示如何用 `sbrk` 划拨内存，进而引导读者思考如何设计元数据、管理空闲块以实现真正的分配与释放。虽然这个为了教学而简化的实现效率不及 glibc 中的生产级代码，但它与真实 `malloc` 的实现原理一致。对于想深入理解内存管理、打破 `malloc` 黑盒的开发者而言，这篇文章提供了一条清晰且可动手实践的路径。

IT 累计浏览 1,504

伙伴分配器的一个极简实现

这篇讲的是内存分配算法“伙伴分配器”的一个极简实现。文章从Linux内核经典的伙伴系统出发，将其核心思想抽象出来，并聚焦于GitHub上wuwenbin的一个极简版本，详细拆解了它的设计与实现。作者将复杂的内存分配问题，巧妙转化为对一棵完全二叉树的管理。每个节点用一个数字（`longest`）标记，直接表示其对应内存块中最大连续空闲单元的大小。分配时，深度优先搜索找到合适节点并将其标记为0；释放时，则回溯并检查相邻节点，通过简单相加判断能否合并。整个过程在O(logN)时间内完成。文章的精妙之处在于对比了另一种用四个状态（UNUSED/USED/SPLIT/FULL）管理节点的实现。极简版通过“`longest`”这一个数值，同时承载了状态和权重信息，避免了复杂的状态机和额外的条件判断，让分配、释放的逻辑变得异常清晰和优雅。这种“少即是多”的突破常规思维，正是其被称道的原因。

IT 累计浏览 10,400

linux内核研究笔记(一）内存管理 – page介绍

这篇讲的是 Linux 内核内存管理中最基础的数据结构——`struct page`。作者以一名服务器程序员的视角，从对“虚拟内存”的好奇出发，深入内核底层，剖析了物理内存管理的核心。文章首先展示了 `page` 结构体的关键字段，并指出它是内核描述物理内存页的最小单元。核心在于，这片物理页在不同场景下被赋予不同角色：作为页缓存（`mapping` 域）加速文件IO，作为私有数据（`private` 域）用于缓冲或交换，或作为页表映射支撑用户空间的 `malloc`。作者进一步通过宏定义，解释了页帧号（pfn）与 `page` 指针、物理地址、内核逻辑地址之间的转换机制。比如 `pfn_to_page` 本质上是操作全局数组 `mem_map`，巧妙地将连续的物理内存抽象为可索引的对象。文章还厘清了“内核逻辑地址”与“内核虚拟地址”的区别，并点明在 x86_32 架构下 `PAGE_OFFSET` 的由来。理解 `page` 结构是窥探内核如何管理伙伴系统、slab分配器乃至整个虚拟内存系统的钥匙。这篇笔记从最底层的数据结构切入，为后续理解更复杂的内存管理机制打下了坚实基础。

IT 累计浏览 4,700

C语言全局变量那些事儿

这篇讲的是C语言全局变量多重定义的“危险”与“微妙”行为。作者从全局变量在不同视角（程序员、编译器、计算机）下的不同含义切入，通过三个递进的代码示例，深入剖析了编译链接器对“强符号”与“弱符号”的解析规则。文章揭示了一个常被忽略的隐患：C语言实际上“允许”全局变量的多重定义（只要不是多个强符号），这可能导致内存被意外覆盖。示例中，同一个变量名在不同文件里可以是结构体或整型，却链接到同一块内存，其初始化值会发生覆盖。作者进一步展示了在多进程（fork）环境下，这种行为如何与操作系统的“写时拷贝”机制相互作用，使得不同进程的同一虚拟地址映射到不同的物理内存，从而产生隐蔽的状态差异。最后，通过将代码编译为静态库链接，作者验证了这种行为在静态链接下依然存在。这篇文章的价值在于，它用具体而震撼的运行结果，将抽象的链接原理和潜在风险可视化，提醒开发者谨慎对待全局变量，尤其是非static限定的全局变量。

IT 累计浏览 6,321

malloc()之后，内核发生了什么？

作者从一个常见的用户空间操作出发，即进程调用 `malloc()` 后尝试访问内存，一路追踪到内核空间的真实发生过程。文章的核心在于揭示，用户感知到的“内存分配”在内核层面主要通过 `brk` 系统调用来实现，其背后是一套从修改堆描述符到最终响应缺页异常的精密机制。讲解路径非常清晰：首先，`malloc()` 会触发 `brk` 系统调用，通过 `SYSCALL_DEFINE1(brk,...)` 服务例程来调整进程的堆边界。文中展示了该例程如何检查资源限制、对齐地址，并根据是扩大还是缩小堆，分别调用 `do_brk()` 或 `do_munmap()`。文章的巧妙之处在于指出，此时内核通常并未立即分配物理内存。`do_brk()` 的核心工作是在进程的虚拟地址空间中分配或合并一个线性区间（VMA），为后续可能的操作“预留地盘”。真正的魔法发生在第二步：当进程首次访问这块新地址时，CPU 会因页表项无效而触发缺页异常。文章接着深入异常处理流程，从 `page_fault` 入口，到 `do_page_fault()` 判断异常类型，最终由 `handle_mm_fault()` 接手。在 `handle_mm_fault()` 中，内核才开始真正“分配”物理内存——它确保页目录结构完整，然后调用 `handle_pte_fault()` 完成页框的分配与映射。整个过程生动地体现了 Linux 内存管理中“延迟分配”的核心思想：先给予虚拟承诺，待实际使用时再兑现物理资源，从而优化了内存使用效率。这对于理解内存分配的全链路至关重要。

IT 累计浏览 4,142

Tomcat内存溢出的原因

生产环境中Tomcat内存设置不当容易引发各类溢出错误，这篇文章就系统总结了三种常见情况及其解决思路。最典型的是Java heap space堆溢出，通常发生在98%时间用于GC且可用堆不足2%时。在无内存泄露的前提下，通过调整-Xms和-Xmx参数（建议设为相同值，如1024m）可解决，但需注意其上限受操作系统数据模型、虚拟内存及物理内存限制。其次是PermGen space永久保存区域溢出，多因加载过多Class信息（如Hibernate、Spring框架动态生成类）导致。解决办法是加大-XX:PermSize与-XX:MaxPermSize参数，并需注意它们与-Xmx的总和不能超过系统最大JVM堆支持（如1.5G）。第三种较为特殊，是unable to create new native thread无法创建新线程，这与JVM和系统内存分配比例有关。文章深入分析了JVM占用内存过多时，操作系统可用内存不足以创建更多物理线程的原理，并给出了线程数估算公式。此类问题需要同时调整操作系统与JVM参数。作者从实际遇到的问题出发，不仅列出参数调整方案，还通过测试数据（如32位系统下堆大小限制）和原理分析（如线程创建机制）来支撑结论，强调需要根据不同溢出类型进行针对性诊断才能治本。

IT 累计浏览 5,464

简单理解Memcached的Slab Allocation

这篇讲的是Memcached如何用Slab Allocation机制管理内存。作者从内存分配的基本问题切入，解释了这套机制的核心：它预先将内存划分为大小固定的Page（默认1MB），再将每个Page切成相同尺寸的Chunk，相同尺寸的Chunk集合就构成了一个Slab。这种预分配和分组的方式，能有效减少动态分配内存时产生的碎片。文章进一步指出，通过启动参数`-f`可以调整Growth Factor（默认1.25），它决定了相邻Slab中Chunk尺寸的倍增关系。不过，Slab Allocation并非完美：当实际数据尺寸与Chunk大小不匹配时，会产生内部碎片；当一个Slab无法被其Chunk大小整除，或是某些尺寸的Slab根本没被使用时，也会造成内存浪费。文章通过结构图和工具截图，直观展示了Slab、Page与Chunk的关系，以及Growth Factor对不同Slab中Item尺寸的影响，清晰剖析了这个内存管理方案的利与弊。

IT 累计浏览 7,680

Linux上进程的表示以及入门

这篇分享聚焦于Linux系统中进程的表示与入门，来自一淘数据部太奇同学的技术沉淀。内容面向所有对Linux底层原理感兴趣的开发者。作者从进程的基本概念切入，层层递进。不仅讲解了进程在Linux系统中的原理与具体实现方式，还简述了进程通信中关键的信号处理机制。文章进一步延伸到内存管理的初步知识，帮助读者建立起对系统资源调度的初步理解。整个分享的最终目标，是为读者打开通向Linux内核深处的大门，搭建一个从用户空间认知跃迁到内核世界探索的桥梁。对于想从应用开发迈向系统级理解的工程师而言，这篇文章提供了一个结构化的入门路径，为后续深入内核源码打下基础。

IT 累计浏览 3,221

free命令中的buffers和cached

这篇讲的是Linux系统中free命令输出结果里buffers和cached字段的区别。作者从同事的日常疑问出发，分享了对这两个内存管理概念的深入解析，旨在帮助读者准确理解系统内存状态。在Linux的内存管理中，buffers指的是块设备缓冲区，主要用于缓存文件系统元数据和块I/O操作的数据，比如磁盘写入的临时存储；而cached则是页缓存，用于缓存已读取的文件内容，以提升重复访问的性能。文章详细对比了它们的实现机制：buffers通常与底层磁盘块直接关联，数据可能在系统重启后丢失；cached则基于内存页，可以持久化存储文件内容，即使进程结束后也可能保留。关键差异在于，buffers更侧重于优化原始磁盘操作，适合频繁的读写场景，如数据库或日志处理；cached则专注于文件级别的缓存，适合多次读取相同文件的应用

IT 累计浏览 1,980

Lua State 间的数据共享

在多程序员协作的Lua项目中，数据共享常成为性能瓶颈。这篇讲的是如何在Lua State之间实现高效数据共享，以解决团队开发时需要在不改动接口的前提下提升性能和扩展功能的现实需求。作者从实际项目出发，面对10名开发者并行工作的情况，发现传统状态隔离方式导致数据同步开销大，影响了迭代效率。文章核心方案是设计一种轻量级共享架构，利用Lua的表引用和弱引用机制，允许不同State通过共享内存区域直接访问数据，避免频繁复制。实现中巧妙结合了元表代理和垃圾回收策略，减少了竞争条件和内存泄漏风险。作者提供了具体优化细节，比如在查询密集操作中性能提升达25%，同时确保了系统稳定性。这种架构不仅加速了现有功能的改进，还为未来模块扩展预留了灵活接口，让项目能更从容地应对复杂需求变化。

IT 累计浏览 5,141

Memcached内存管理机制浅析

作者从 Memcached 源码入手，深入剖析了其内存管理的核心机制——Slab Allocation。不同于简单介绍，文章直接切入 Memcached 为解决内存碎片化问题而设计的这套高效方案。核心思路是将内存预先分割成固定大小的内存块（Slab Class），每个 Slab 内部再细分为相同尺寸的 Chunk。当数据存入时，Memcached 会根据数据大小找到最匹配的 Slab Class，从中分配一个 Chunk。这种“分类定长”的分配方式，极大减少了内存碎片，提升了分配与回收的效率。文章还具体分析了 Slab 的扩展策略以及内存池（Memcached_arena）在其中的作用。通过源码级解读，文章清晰地展现了 Memcached 如何用看似简单的“空间换时间”策略，实现了高性能、低碎片化的内存管理，揭示了其在实际高并发场景下能够保持稳定高效的底层原因。

IT 累计浏览 5,761

iOS内存暴增问题追查与使用陷阱

这篇讲的是iOS开发者如何追查和预防那些令人头疼的内存暴增问题。作者从开发者常遇到的内存莫名增长、程序崩溃等场景切入，系统梳理了iOS内存管理的核心——引用计数机制与autorelease池的工作原理。文章重点剖析了两个层面：一是基础但易错的“谁创建谁释放”等使用原则，以及深浅拷贝、属性声明（如retain与assign）可能埋下的陷阱；二是对autorelease机制的深度解构，解释了为何滑动列表、频繁加载图片或操作数据库时，内存会“悄悄”增长，根源常在于未复用cell、大量未及时释放的解码缓冲区或数据库连接缓冲。此外，文章还梳理了收到系统内存警告后的处理流程，并结合实例介绍了排查工具的使用。整体上，它不仅点明了“坑”在哪，更提供了从编码规范到机制理解、再到工具实践的一套解决思路，帮助开发者更稳定地管理应用内存。

IT 累计浏览 3,602

内存学习――虚拟内存

这篇讲的是虚拟内存的核心机制与设计逻辑。文章紧接上一篇对“为什么需要虚拟内存”的探讨，深入到具体实现层面，解释了操作系统如何通过页表、缺页中断等机制，将进程的逻辑地址空间映射到物理内存，从而构建出一个稳定、隔离且大于实际物理内存的虚拟环境。作者从进程的视角出发，阐述了虚拟内存如何让每个程序都“错觉”自己拥有连续完整的内存空间，而底层物理内存却可能被分散地分配在不同位置。文中可能会剖析关键的内存管理单元（MMU）工作原理，以及当程序访问的页面不在物理内存时，系统如何通过换入换出机制透明地完成数据调度。读完这篇文章，你不仅会明白虚拟内存“是什么”，更能理解它“为什么这样设计”——比如如何实现内存保护、简化编程模型，以及在资源有限的系统上高效运行多个进程。这些底层细节是理解现代操作系统性能优化和故障分析的基础。

IT 累计浏览 5,081

内存学习――为什么需要虚拟内存

这篇讲的是虚拟内存存在的必要性。作者从自己初学时对物理内存、虚拟内存的模糊认知出发，梳理出两者最核心的差异：物理内存是真实、有限的硬件，而虚拟内存为每个进程提供了一个独立、连续且远大于实际内存的地址空间。文章清晰地解释了这种抽象如何解决进程隔离、内存安全以及高效利用物理内存这几个关键问题，比如让每个程序“以为”自己独占内存，实际上则由操作系统在幕后将虚拟地址映射到真实的物理页帧。作者通过具体的逻辑推导，阐明了虚拟内存作为现代操作系统基石的作用，帮助读者从“为什么”这个源头建立起理解。